outofthebluefandomcom-20200215-history
Group Post Mortem
Summary Group 1 is made up of six members, Johan Danielsson, Emil Ekeroth, Teodor Granberg, Simon Gunnarsson, Marcel Markov and Alfred Skedebäck. We had weekly meetings, discussing our progress, working on current assignments and decided what to until the next meeting. We made a prototype, tested it a lot and gave it to other groups to test. Then we made a final version. We are all pretty happy with how it turned out. We are however less happy with how our hierarchy and our rule writing turned out, and we had a slight problem with attendance. All things considered the project was a success. Introduction This report will evaluate our work process during the production of the game Asteroid mining. We will analyze our work and try to pinpoint what we did right and what could have been done better. Asteroid mining is a board game set around greed, risk and reward. The players take control of a mining-robot and the goal is to harvest as much minerals as possible and make it out of the mine alive. The core system is based around the player’s deck. Since the resources are put in the same deck as the action-cards, the more resources the player collect, the chance of drawing an action-card is diminishing. We chose to design it this way to symbolize that the player is being weighed down by the minerals and can’t move as fast. The challenge is to balance the deck while gathering as many minerals as possible, but still be able to make it up to the surface. More resources also mean that the player will be more vulnerable to thievery and likely the target of the other players. Plan In the pre-production phase we brainstormed for some ideas for a game. To get an overview of what we wanted to do, we made a list of things that we wanted the game to convey. This included goals like; a game that is easy to learn, fun to play, and a game focused on player interaction. Goal The players should feel the need for greed; they should try to gather as much resources as possible at any cost. They should also feel that they have multiple choices and that they can outsmart their opponents. Success: The player should feel that they become richer as the game goes on. The player should feel that it is beneficial to steal from their opponents. The player who makes the best choices should win the game most of the times. (I.e. a game with few random parameters.) The players will feel that they have more and better choices when they spend their resources. Failures: If the player feels that their resources are not worth enough. If they do not feel the competition versus the other players. If the player feels that they have too few choices, too often. If the player experience a general feeling of unfairness. Method Prototyping the system We started out by testing our system with classic playing cards. At first we had a resource system that used different “action-cards” and “point-cards”, where the player had to balance their resources to succeed. Since we wanted the players to feel as if they had several choices each turn, we made cards that gave the option to choose between three different actions each time they are played. We also made a board to play on, with pen and paper, to get a sense of how the game will play out. Later we iterated the board to suit the game and balance the pacing. Aesthetics After we had made a prototype of the system we made a list of aesthetic goals. This was used through MDA to envision how we wanted the player to feel when playing our final game. Fabrication For our prototype we bought some A3 sized papers, which we cut up in card shapes and then drew basic symbols on, just to have something to use during the many tests. We later drew better pictures in Photoshop, which we printed out on and cut out. We put these cards in plastic page protectors, and that made our pieces feel more “real”. What went right Planning The first thing that came to our minds that we did well was the planning. As soon as we knew our assignment and all of the group members that was in our group we figured out which weekdays worked best for everyone in the group. This was a bit complicated as we had to schedule around four different courses, but we noticed that Wednesdays worked for everyone in the group most of the weeks. We wanted at least two meetings each week so we tried to the best of our abilities to have one more meeting either earlier or later in the week. In the end we managed to have a minimum of two meetings or more each week. We had these meetings on top of our other courses, so these weeks have been hectic, to say the least. We didn’t have a time limit on these meetings; we met at 10 in the morning and worked until we felt satisfied for the day. Between these meetings we also tried to figure out at least one thing to do each for the next meeting. These assignments varied much, depending on what stage of production we were in. In the beginning these could for example be; to think about some kind of new action we could use for our action card system, or in the later stages these assignments could be to actually make the final version of our cards over the weekend. We made sure that we knew exactly what to buy and what to do, before we called it a day. Teamwork The teamwork within the group has been very smooth and solid. Even though we had our individual roles within the group and some of us had the final say within their area, we kept the decision making rather democratic. Usually we discussed the balancing changes and rules together and when we had different opinions, we listed the pros and cons and decided as a group. At some points, when we couldn’t decide something as a group, the person who was responsible for that area took the decision, for example; the design of the logo and some of the cards. The way of deciding things democratically worked fine for us because we were so few members in our team, we could make every voice heard, and we could have a discussion about the decision. If we had been more than six persons, this probably wouldn't have worked out. Using the M.D.A.-framework When we made the game we made frequent use of the M.D.A.-framework (mechanics, dynamics, and aesthetics). This helped us to talk about the system and game in more manageable chunks. We started by talking about the system and how it should work, but this only got us so far. We noticed that we needed a frame of context to work around, to be able to look, and talk about the system more easily. We still kept the theme very abstract, but used it to define the system. This way we could see where we were going but still have a good overview of the core-system. By going up and down along mechanics, dynamics and aesthetics we managed to form the system and look at the components more easily. This helped a lot and we will definitely use this in future projects. What went wrong Hierarchy As stated before, we had a rather flat hierarchy when deciding things. Even though we managed to get along and produce good result by doing so, this could have been handled better. For one thing, the roles could have been more specific. Most balance- and design decisions were discussed as a group before we reached any decision. If we as a group had decided a clear goal early and the producer had assigned clearer roles for specific areas of responsibility the decision making process could have been more effective. On the other hand, the process of making decision where everyone was involved can be argued to have positively influenced the final product. As everyone was involved, fewer issues were overlooked and the kinks were straightened out by a larger variety of individual experience and knowledge. Attendance Another thing that could have been better but still worked out fine was the attendance. Some days a few people were late and therefore we could have worked more effective if everyone was always on time. But actual time that the group lost due to late arrivals was not that much and did not interfere too much with the actual work hours and the final product. Arriving late is not a problem when working in a small group in a project that is just a few weeks long. The real problems appear when you’re working in a larger group and/or in a project with a longer time frame. For example; if one random person is late five minutes every meeting and you have two meetings each week and we say that the rest of the group does not start working until the last person arrives, you lose one hour of active work time every week. During a work period of four weeks you will have lost four hours in total, and this is just if the person is five minutes late. On a smaller project the time loss can be counteracted by harder work but in a bigger project, it would be almost impossible to counteract the time lost, you would simply have a worse product in the end. Rules Both groups that tested our game the first week thought the rules were confusing. This is probably because the rules felt so obvious to us, and we had to abstract the game a lot. We could not include a theme and this makes it harder to both relate to the rules and to write the rules. Another reason why our rules were confusing to the teams playing our game is simply that none of us have written rules to a board game before. We have done workshops where we designed board games and wrote some simple rules as well, but in these workshops there has always been the opportunity to observe and explain or interfere if there are any problems or “bugs” in the design or rules. This far we have only explained reasons and exceptions to why we did not write the rules better so we are now going to explain how we could have done this even better instead of trying to take the blame away from us. We did not use enough time to write the rules. Writing the rules was given as an assignment to be done over the weekend for the two programmers to do. They did not finish writing the first draft of the rules until midday on Sunday the day before the first week of play testing was supposed to start. This meant we had too little time for the rest of the group to help proof-reading and to correct mistakes until we had to print the rules for the first testers to use when playing. But this process has taught us that more time is needed to write coherent rules. You also need to plan how to write the rules, to be able to communicate the most important parts of the game. Conclusion All though we had no scheduled time for this project we managed to make some time in between our other courses. We are all very pleased on how our game turned out in the end and the path that lead us to it. We’ve had a great work flow in our process and we’ve also been quite lucky. We somehow avoided major setbacks or moments of slow process and even sometimes managed to make things so balanced that, the more we play our board game now, we realize that we couldn’t have balanced it better. You could argue that not having any major drawbacks or conflicts does not help us improve for projects that we have ahead of us, as it is important for groups to be able to handle conflicts and crisis situations. We think it is a result of us having worked in projects before and learned a lot of how to work as a team. It is important to always dare to say what you think when some problems or uncertainties arises so that you can handle the problem straight away, avoiding small problems to grow. Everyone in the group was also good at handling feedback as well as everyone was good at giving constructive criticism and not just arguing. In the end we are happy with the teamwork and how the group decisions led to the final product. But we also understand that we have to focus more on the roles within the group in the future.